Digital video system using networked cameras

ABSTRACT

A digital video system including a computer connected via a network to a number of video servers and cameras. The computer includes a program that provides a grid of display windows, each of which displays an image received from the camera associated with that window. The program sequentially polls each camera, accessing and displaying an image from the camera in its associated window. The program can access the cameras at different frame rates. The program stores image streams in a single file, concatenating each successive image onto the end of the file. The file is then indexed using SOI and EOI markers to permit fast access to individual images within the file. The program can monitor received video and automatically start recording upon detecting motion within the video stream. Motion detection is implemented by comparing color component values for pixels from different images.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.09/808,543, filed Mar. 14, 2001, now U.S. Pat. No. ______, which claimsthe priority of U.S. Provisional Application Ser. No. 60/189,162, filedMar. 14, 2000. The entire disclosure of U.S. application Ser. No.09/808,543 is hereby incorporated by reference.

TECHNICAL FIELD

This invention relates to systems for accessing, recording, anddisplaying camera images from any of a number of remotely locatedcameras and, more particularly, to such systems that provide access toimages from one or more remote cameras over a public or private computernetwork.

BACKGROUND OF THE INVENTION

With the continuing expansion and availability of public and privatecomputer networks it is becoming increasingly common to use thesenetworks for remote video and image surveillance. Historically, analogsystems have been used for CCTV systems for purposes such assurveillance. They include an analog video camera, a video cable, and amonitor/TV and/or a VCR recording device. Multiple cameras can be hookedto multiple recording VCRs for complete coverage of one or more targetareas. Specialized equipment known as a multiplexer or ‘MUX’ can be usedto allow multiple cameras to be hooked to a single recording/viewdevice. The multiplexer takes all video feeds in a sequential fashion,recording from one camera at a time. This allows the quantity of camerasto share a single recording tape. Besides the limitations of a serialtape system, additional limitations are introduced when the sequencingrate of the multiplexer is too slow to allow sufficient videorecord/view speed of a given camera view. Multiplexers are typicallyexpensive and have limited expandability without purchasing additionalcomplete systems. Also, the configuration of these systems usuallyrequires a skilled technician to be available at the systems site whichincreases the total cost of implementing such systems.

Digital systems have become more prevalent with the advent ofstandardized digital componentry. These systems utilize the same analogcameras and cabling, but introduce a capture card based collector. Thiscollector can be a proprietary digital device or a PC based computer,either of which has analog video inputs directly connected to it. Theseinputs convert the video to digital for viewing and recording and mayeven retransmit the signal to analog tape for recording purposes. Afactor limiting these digital systems is that an autonomous computer isrequired relatively near the video sources, sometimes with userintervention required at regular intervals. These machines are alsohardware bound. The number of capture cards is limited to the specificdesign of the collecting equipment. These systems are usuallyproprietary to a particular manufacturer and can be very expensive.Remote viewing is usually not available. Failover or redundancy functionis also limited and expensive, due to the fact that the system isusually duplicated for redundancy. As with the analog systems discussedabove, these systems also have configuration requirements that typicallyrequire a skilled technician.

There now exists commercially available networkable cameras that can beaccessed over networks running TCP/IP, including both LANs and globalnetworks such as the Internet. Ethernet-based digital video servers arenow common that are small, autonomous, and usually contain a web-basedconfiguration utility, as well as administration software. These camerascan be accessed and, in the case of pan/tilt/zoom (PTZ) cameras,controlled over the network using an assigned IP address and standardCGI-based URL syntax or other manufacturer-specified addressingprotocols. This allows an authorized user to control the product fromanywhere via the Internet or a dialup connection, and allows live imagesand image streams (video) to be accessed remotely using standard webbrowsers.

The video servers exist in two forms. One is a camera server that is acomplete product containing both a camera and a web server with anEthernet port. The other is a component based video server with inputsfor one or more analog video feeds, which the user can connect toconventional camera PAL or NTSC video feeds. The inputted analog videofeeds are converted to digital signals and sent from the video servers'Ethernet port. Thus, the video servers (whether integrated in as part ofa camera server or as a standalone unit) can be connected to theEthernet-based networks commonly used in businesses and other computerenabled sites. These video servers can be connected to these networksegments and are fully compatible with existing data on these networks.The video data can be received by standard PC computers which require nospecial hardware other than an Ethernet connection. The cameras can beeasily configured by a novice user who has very basic experience withthe Internet.

Ethernet video servers connect to an Ethernet connection and deliverdigital video based on user requests or internal scripting agents. Auser requests video images via standard CGI enhanced URL syntaxes. Thesesyntaxes control the image metrics and other features of the requestedvideo stream. The images are sent to the user as either static JPGsnapshots, or as continuous JPG streams. Rates to 30 FPS are easilyattainable. Since these images are delivered by Ethernet, the cameraservers are very robust. Although a requested image may not be receivedcompletely in an expected time frame, the video server will wait for theuser to complete its requests and processing. This virtually guaranteesdelivery of video, except where a connection to the video server isterminated.

When the user requests a video image or stream, the user is actuallyrequesting a static image that appears to exist as a file in a directorystructure on the video server. When the user requests a copy of thisimage, the video server actually updates it with a new image from thecamera source, and the user receives a picture that is up to date.Subsequent requests are to the identical file name, and the server doesthe updating of its content.

Although IP-based network cameras and camera servers have now evolved toa relatively advanced state, the use of a browser-based interface tothis hardware has seemingly impeded development of user interfaces thatprovide simplified, automated control over the acquisition of snapshotand streaming images over the network. Access to the camera imagestypically requires knowledge of the manufacturer's CGI-based syntax toaccess snapshot or streaming images. For example, to access a particularcamera, the user may have to specify to the browser an address in theform ofhttp//Uid:PW@111.111.111.111/cgi-bin/fullsize.jpg?camera=1&compression=1.While this may be handled easily enough for a single camera bybookmarking or pulling the URL out of the browser's history buffer, thetask becomes more difficult when the user desires to change the accessparameters or where different cameras need to be accessed. Where theidentified camera cannot be accessed, such as for example due to animproper address being specified, the user may simply receive a standard“404 not found” error message that is not helpful in diagnosing eitherthe error or actual reason why access was not available.

Moreover, browser-based access is typically limited to either a snapshotmode or streaming images. In the snapshot mode, a single image isreturned when the appropriate URL is entered into the browser.Subsequent images from the camera are then accessed using the browser's“reload” or “refresh” button. In the streaming mode, once theappropriate URL is specified, the remote server or camera simply beginsstreaming image files back to the browser. This results in relativelyhigh network utilization that may be undesirable in a shared networkenvironment.

It is therefore a general object of this invention to provide animproved user interface and approach to the network transmission ofimages from commercially available network cameras.

SUMMARY OF THE INVENTION

In accordance with the invention, there is provided a digital videosystem which includes a client computer, one or more video serversaccessible by the client computer over a network, and a plurality ofcameras connected to the video servers. The one or more video serversprovide an interface between the cameras and client computer, withimages from the cameras being accessed by the video servers and thensent to the client computer upon request by the client computer. Theclient computer provides a user interface display on the computer thatincludes a display window for each of the cameras accessed over thenetwork and that displays in each of the display windows an imagereceived from the camera associated with that display window.

In accordance with another aspect of the invention, there is provided acomputer readable medium for use by the client computer in providing theuser interface display. The computer readable medium includes a digitalstorage device and a user interface program stored on the digitalstorage device in computer readable form. The program is operable uponexecution by the computer to access camera data uniquely identifying thecameras and to attempt access to the cameras over the network using thecamera data. The program is further operable to verify access to thoseones of the cameras that are accessible over the network and to generatethe user interface display and to display in each of the display windowsan image received from the camera associated with that display window.

In accordance with another aspect of the invention, there is provided acomputer readable medium and method for use by a computer in detectingmotion in a sequence of color video images received by the computer. Thecomputer readable medium includes a digital storage device containing aprogram that is operable to carry out the motion detection. The programselects one of the video images as a reference image and another of thevideo images as a selected image to be compared to the reference image.The program then accesses a color component value for each of a numberof pixels from the reference image and for each of a number ofcorresponding pixels from the selected image, with the program beingoperable to perform pixel comparisons using the color component valuesand to generate a motion detect signal when the difference in colorcomponent values for corresponding pixels from the reference andselected images differ by more than a preselected amount.

In accordance with yet another aspect of the invention, there isprovided a computer readable medium and method for use by a computer inrecording a sequence of images, each of which comprises an individualimage file in which the image is represented in a graphics file formatthat includes a first marker identifying the start of the image and asecond marker identifying the end of the image. The computer readablemedium includes a digital storage device containing a program that isoperable to carry out the recording. The program stores the imagestogether as a single file that comprises the group of imagesconcatenated together in sequential order. The program is operable toindex the file using the first and second markers. This index can thenbe used to provide quick access to individual images stored within thesingle file.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred exemplary embodiments of the invention will hereinafter bedescribed in conjunction with the appended drawings, wherein likedesignations' denote like elements, and wherein:

FIG. 1 is a block diagram showing a preferred embodiment of a digitalvideo system of the present invention;

FIGS. 2 and 3 together depict the process flow of the user interfaceclient application of FIG. 1;

FIG. 4 shows the contents of the initialization file used by the userinterface client application of FIG. 1;

FIG. 5 is a diagram depicting the main menu structure of the userinterface client application;

FIG. 6 is a flow chart showing the process used by the user interfaceclient to provide hardware setup information;

FIG. 7 is a diagram depicting the server setup form displayed by theuser interface client;

FIG. 8 is a diagram depicting the camera setup form displayed by theuser interface client;

FIG. 9 is a flow chart showing the process used to display a motion formthat allows the user to display and record video streams from one of thecameras;

FIG. 10 is a flow chart showing the process flow for the image viewerprogram of FIG. 1;

FIG. 11 is a diagram depicting the menu structure of the image viewerprogram;

FIG. 12 a is a flow chart of the autoindexing setup process used by theimage viewer program;

FIG. 12 b is a flow chart of the archive delete process used by theimage viewer program;

FIG. 13 is an overview of an OCX control used by the user interfaceclient and stream recorder client applications of FIG. 1;

FIG. 14 a is a flow chart of a portion of the OCX control that is usedto access individual snapshot images from the cameras used in thedigital video system of FIG. 1;

FIG. 14 b is a flow chart of a portion of the OCX control that is usedto intermittently access images from a streaming image server;

FIG. 14 c is a flow chart of a portion of the OCX control that is usedto access full video streams from a streaming image server;

FIG. 15 is a flow chart of a portion of the OCX control that is used inthe processing and recording of received images and image streams;

FIG. 16 is a flow chart showing the process flow for the stream recorderclient application of FIG. 1; and

FIGS. 17 a and 17 b together depict the motion detection routine used bythe user interface client application of FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to FIG. 1, there is shown a network setup of a digital videosystem 20 of the present invention. The video system 20 includes aclient computer 22, a plurality of cameras 24, and one or morestandalone video servers 26. The client computer is connected to thecameras 24 and video servers 26 via a network 28 which can include aprivate network segment 30 and a public network such as the Internet 32.Other networked components can be used such as a networked storagedevice 34 and a networked file server 36. Some of the cameras 24comprise camera servers 38 which include both a video server and camerain a single integrated unit. The camera servers 38 can be, for example,Axis™ 200, 200+, or 2100 Ethernet cameras, available from AxisCommunications Inc., Chelmsford, Mass. (www.axis.com). The video servers26 can be Axis™ 2400, 2401, or 240 video servers, also available fromAxis Communications, Inc. The cameras 24 that are connected to the videoservers 26 can be industry standard PAL or NTSC video cameras. Clientcomputer 22 can be a conventional personal computer having an Intel™ orcompatible CPU running a Windows™ operating system and including anetwork interface card (not shown) for connecting to the 10/100 MbEthernet network 30 that uses the TCP/IP network protocol.

In accordance with the invention, client computer 22 includes a computerreadable memory, such as a fixed hard drive shown at 40 containingmagnetic media for digital storage of a user interface clientapplication 42 that includes a user interface program along with anumber of additional software components. The user interface program isin computer readable form (such as an .exe file). The additionalsoftware components include Microsoft™ Internet Explorer™ Internetextensions (included with Windows™ 95, 98, ME, 2000 and revisions), theWin32API libraries (included with Windows™ operating systems), theWinInet.dll (also included with Windows™ operating systems), and acompression library such as IJL115.dll (available from Intel™) to decodeand recompress jpeg images received from the cameras 24.

Although the user interface client program 42 is shown as being storedon a hard drive 40, it will be appreciated that it can be stored onother digital storage devices as well. As used in the specification andclaims, “digital storage device” includes any of a variety of differentdigital storage devices, including magnetic media such as a hard disk orremovable disk, optical storage media such as a CDROM or DVD, ormagneto-optical media.

In general, the user interface client program 42 is operable to accesslocally stored camera data that uniquely identifies the cameras 24 andthen attempts access to those cameras over the network 28. The program24 is operable to verify access to at least those cameras 24 that arecurrently accessible, and to generate a user interface display 44 (onthe computer's monitor) that includes a display window 46 for each ofthe cameras 24 accessed over the network 28, and to display in each ofthe display windows 46 an image 48 received from the camera associatedwith that display window. As used in the specification and claims inreference to the program 42 or other executable program code, the phrase“operable to” [carry out some action] means that, when executed by amicroprocessor or other processing device of the computer, the programdirects the microprocessor to carry out or otherwise cause execution ofthe specified action.

In addition to the user interface client application 42, the hard drive40 also contains a stream recorder client application 50 and an imageviewer 52. Stream recorder client 50 permits high speed recording ofstreamed images (video) in a manner that minimizes network bandwidthutilization. Image viewer 52 permits browsing and viewing of archivedimages and video using a playback screen display 54. These two programs50, 52 are discussed farther below in connection with FIGS. 10-12 (forviewer program 52) and FIG. 16 (for stream recorder client 50). Allthree programs 42, 50, and 52 can be developed under Visual Basic 6.0and Visual C++6.0 and designed to run under Windows™ 95, 98, ME, NT, and2000. User interface client 42 stores all camera, server and imagesettings to a Microsoft Access™ 7.0 database 56 and camera and userconfiguration data is stored in an .ini file 58. Digitized recordedvideo is stored directly on hard disk 40.

The user interface client application 42 is depicted in various levelsof detail by FIGS. 2-9 and 13-15, and 17 a-17 b, with FIGS. 2 and 3together representing the complete process flow through the applicationstarting from program launch. As shown in FIG. 2, once the user hasconsented to the licensing terms for use of the program, variousinitialization steps are performed, including:

-   -   1. getting camera and user configuration data from the .ini file        58;    -   2. initializing the database tables 56;    -   3. configuring the layout of the display form 44 on the client        computer 22;    -   4. reading the camera setups from the database table 56;    -   5. validating or creating the base path (directories) for        recording of images and image streams;    -   6. formatting user-selectable buttons for the client user        interface 44; and    -   7. retrieving embedded MAC addresses for purposes of validating        access to the cameras 24 identified in the database 56.

Thereafter, program 42 generates the user interface display 44 and theuser can start accessing images or video or can access various menuoptions shown in FIG. 5 for purposes of maintenance or changing of setupinformation. If the user has selected “start” to begin accessing imagesor video, then the next step is to initialize and test the camerasand/or servers by verifying the IP addresses, testing for a valid MACaddresses, and, if the IP addresses and MAC addresses are valid,assigning the user settings and enabling or disabling individual camerasor servers. As is known, the MAC addresses are unique to each camera andserver and can be queried via FTP requests to protected areas of thecamera or server's memory. Specific locations vary by manufacturer andrequire parsing and formatting to extract the required data, as will beknown by those skilled in the art. This enables the software to belicensed on a per-camera or per-server basis and can be used to preventaccess to any cameras or servers for which the user is not licensed.

For each camera in the database 56, all control information assigned tothat camera is stored in an array data type. This control informationincludes: Server Enabled, Server Name, Server Model, Server ID, ServerIP, Server Mac, Server User ID, Server PW, Server Port, Cam ID, CamModel, Cam Enabled, Cam Name, Cam Location, Cam Bldg, Cam Room, Cam Tel,Cam Room Contact, Cam Room Contact Tel, Cam Notes, Board Switch PortNums, Cam Thumb Image Name, Cam Fullimage Name, Record Image Name, CamThumb Compression Level, Cam Full Compression Level, Cam RecordCompression Level, Tool Tip Text, Last Pan, Last Tilt, Last Zoom, CamPTZ (y/n), Server Switch Action, Switch Caption, Switch Notes, EmailNotification, Email Address, Email Message, Enable Audio Alert, PlayAudio File, Last Update Time, Time Lapse Interval, Tie Breaker Count,User Disabled, System Disabled, System Disabled Message, RecompressionValue, Pan String, Tilt String, Zoom String, Home String. Theseparameters all control the camera and/or server used by the applicationand can be changed via a hardware setup form that is provided by thesoftware for the user and that is described further below.

Once all tests are complete, the process moves to FIG. 3 where theprogram ‘listens’ for digital input triggers generated by any of thecameras supporting this function. The client program 42 can listen forthese trigger events and either flash or highlight the window associatedwith that trigger input, show a high frame rate view (motion window) orbegin recording an image or series of images in the above formats.Trigger events are recorded to one of the database 56 tables byrecording the date, time and image name. The user can review and accessimages saved during triggering. As will be known to those skilled in theart, triggering is accomplished by enabling a CRON script in the serverthat will send a message to the client computer 22. Program 42 useswinsock controls to listen on a predefined port (1111 default). If atrigger message is received, the message is parsed for the server ID andport number. This information is compared to the relevant data fromdatabase 56 and the appropriate display window 46 is activated. The CRONscript comprises one or more control instructions generated by program42. Although the CRON script can be generated directly using a webbrowser on the client computer, it will be appreciated that generationof the CRON script by program 42 eliminates common typographical errorsencountered in manual CRON programming. Unique identifiers such as hostPC and port are automatically added to the CRON script by program 42.

Once the process begins listening for triggers it then finishesconfiguring the user interface display grid 44 on the client computer22. The display grid 44 shown in FIG. 1 is a 3×3 grid for up to ninecameras and it will be appreciated that any size grid can be specified,with the program 42 permitting the user to specify the number of windowsand the program then automatically scaling the images 48 to fit theresulting display window size. In configuring the view grid, the program42 may disable some camera images 48, showing instead a “No Video” orother message in the display box 46 associated with the camera 24. Thisdisabling may be due to, for example, the camera 24 being unreachable,disabled, or invalid. The software also sets the “record” indicators (ifenabled), the show port numbers (if enabled), and the camera caption(camera name, if enabled). These are discussed below in connection withFIG. 5.

Once the screen display 44 has been configured, the display loop beginsin which the program accesses and displays images from the cameras 24 onthe user's screen, with the software periodically updating the displayof each image 48. Starting with the first camera displayed, the programsequentially accesses each camera 24 and displays the received image 48in the box 46 associated with that camera, scaling the image to fit theuser's selected view size. The process runs through the display looponce for each camera 24, incrementing the current frame (display box)for each iteration until it has retrieved and displayed a snapshot imagefrom each camera. It then continues looping through the display loop,starting again at the first camera, and runs through the processcontinuously, sequentially polling each camera and updating each window46 with an updated image 48 received from the associated camera. As eachdisplay window is being updated, it can be highlighted using, forexample, a colored border to distinguish it from the remaining displaywindows. This allows the user to see the sequential polling process andis especially useful where the images change little if at all from oneupdate to the next.

The display loop of FIG. 3 continues until either a trigger event isreceived, a double-click by the user is detected on one of the displayedwindows 46, a stream request is made by double-clicking the port numberon the camera window, or the user cancels the monitoring, in which casethe program pauses. If the user selects a window 46 by double-clickinganywhere on its image 48, a motion form is displayed that permitsviewing a setting of various camera parameters, as well as permittingthe user to set recording parameters (such as number of frames tomanually record) and initiate recording from the camera associated withthe selected display window. The motion form and its use will bedescribed further below in connection with FIG. 9. The program checksduring the display loop to determine if the user has enabled recording.If so, the program checks user recording settings that can be setthrough the hardware setup process of FIG. 6 using the recording camerasetup tab of FIG. 8. These user configurable settings include selectionsto record all frames received, or interval recording where the user canspecify that frames are only recorded once every so many seconds orminutes. The user can also specify that recording should only occur whenmotion is detected in the received video. A preferred routine forimplementing the motion detection will be described further below inconnection with FIGS. 17 a and 17 b. Once these user settings are read,the program then checks scheduler settings that are also userconfigurable under the recording camera setup tab. These schedulersettings allow the user to specify certain hours during the day and daysduring the week when the recording is either to occur or be blocked.Scheduling can be done in 15 minute intervals. Every 15 minutes the usercan select No recording, Standard Recording (FIG. 15), or Video MotionDetection Recording FIGS. 17 a-17 b). The program will compare thisschedule to the current time of day and adjust the recording functionsas necessary. This allows for up to 96 different recording schedules perday, far exceeding any typical user need. If recording is permitted forthe current time on this particular day, then the program proceeds tothe appropriate recording routine (record all frames, time intervalrecording, or motion detection) according to the user configurablesettings previously read.

As a part of the display loop, program 42 requests images or videostreams from one of the cameras 24. The requests are formatted asstandard CGI based URL syntax, i.e.:

-   -   http//Uid:PW@111.111.111.111.111/cgi-bin/fullsize.jpg?camera=1&compression=1).

The images are downloaded from the cameras 38 and servers 26 to theclient computer 22 where they are stored in a memory buffer, which canbe implemented in RAM. The buffer is parsed and augmented with formatteddate and time stamps, accurate to the millisecond. The image is assigneda name generated by the program based on the date and time of creation.The program 42 then saves the image to the hard drive 40 using thefollowing directory structure:

-   -   Mapped Drive and Root Path/Server Name/Camera        Name/Year/Month/Day

This directory structure is generated in real-time as the recordingexecutes. The images are saved in one of the following styles, based onuser setup preferences:

-   -   Single Images: Images are saved under the Day directory in a        graphics file format such a jpegs. The file naming convention        used is hh mm ss.jpg, where hh is the current client computer        clock hour in 24 hour format, mm is minutes, and ss is seconds.    -   Multiple Images (video): Video images (i.e., time sequences of        individual images) are saved at the Month directory level as hh        00 00.jpx, where the .jpx extension represents a jpeg        concatenation file (streaming jpeg), which is a single file that        is built by the program 42 and that comprises a series of jpeg        images concatenated together. hh is the client computer clock        hour in 24 hour format. These .jpx files can be read and played        back by the image viewer 52.

Before storing the jpeg image files or concatenating the jpegs onto ajpx stream, the images can be compressed using the compression .dlllibrary noted above. In practice, it has been found that good qualityrecorded images consume an average of 7,500 bytes per image. Highercompression levels can yield a smaller file (down to 2,500 byes) at areduced quality. Higher quality images can also be recorded at a filesize of 70,000 bytes per image up to 250,000 bytes per image.

The program 42 can acquire images from the cameras in any of threemodes:

Snapshot: Request one image from the server and close the connection. Byrunning through the display loop rather than requesting a continuousstream from the server, the program iteratively requests snapshots fromthe cameras and servers thereby providing continuously-updated images ina manner that requires little bandwidth, with network utilizationtypically peaking at no more than six percent, regardless of networksize.

Stream Frame Mode: Connect in stream mode to each camera andsequentially cycle through each of the cameras, obtaining one or more ofthe streamed images from one selected camera, pausing the streaming fromthat camera, and then obtaining one or more streamed images from thenext camera until all of the cameras have been accessed and then paused.This cycle is repeated continuously until the user switches the programback out of this stream frame mode. In this mode, the processing isidentical to that of the snapshot mode, with the display loop extractingat least one frame from an open stream, and then indexing to the nextcamera. The connection is periodically reset to remain robustness. Thisapproach to image acquisition yields substantial performance gains overthe snapshot mode and is more efficient that a continuous stream. Thisconnection allows the video server to maintain an authorized connectionto the client computer, providing enhanced performance and ultimately,augmented received frame rates. Running in this mode requires morebandwidth than the snapshot mode, but will utilize less than the fullstreaming mode described below, since each stream is paused as theremaining connected cameras are sequentially accessed for a frame ofvideo. The video server buffers surplus video to the point of filling upits internal buffers, at which time the server stops grabbing videoframes until the buffer is depleted, or the server is reset. Thus, aswill be appreciated by those skilled in the art, this approach can alsobe used to control the frame rate of displayed and/or recorded video ina manner that minimizes the network bandwidth utilization. Thus, it canbe used for only select ones of the cameras and for recording at a framerate faster than that obtained by individual URL calls, but less thanthat provided by full streaming from the camera or video server.

Full Streaming Mode: Launch the stream recorder client 50 as a shelledprocess, pass the URL and various options via a command line syntax. Theclient computer connects in stream mode and retrieve images in aninfinite loop. The connection is reset periodically to ensure robustconnectivity across various network topologies. The received imagestream is then parsed for SOI (ASCII 255+ASCII 216) and EOI (ASCII255+ASCII 217) markers, which are the standard start-of-image andend-of-image markers. A buffer is built until these markers are found.When found, the image is displayed and that section is removed from thebuffer. This process is then reiterated until a timer expires thesession or the user manually closes the connection.

When recording, the stream recorder client 50 writes directly to thesame directory used by program 42, but uses a different namingconvention to avoid contention. This naming convention can beimplemented by appending a letter suffix to the filename of the jpxstream. For example, program 42 might record a filename as “11 0000.jpx”, whereas program 50 might record images obtained at the sametime as “11 00 00_s.jpx”. Since they are now uniquely named, there is noconcern of one program overwriting the image files of the other.

Referring now to FIG. 4, the .ini configuration file used for program 42will now be described. The WindowState=Normal (or Maximized) sets themain camera view grid as either normal, with the display being sizedbased on the Images_Across, Images_Down, Ref Image_Width, andRef_Image_Height parameters. The Ref_Image_Width specifies the imagewidth of each display window 46 in units of twips (which is a knownmeasurement unit defined by Microsoft™). There are approximately 1440twips per inch. The image width is determined by the default imagemetrics that can be specified by the user via the defined inSetup/Software menu command. The Images_Across parameter specifies thenumber of cameras to be shown horizontally within the user interfacedisplay 44 and the Images_Down parameter specifies the number of camerasto be shown vertically. An exemplary 3×3 display grid (for a total ofnine camera windows) is shown in FIG. 1. In the event thatWindowState=Maximized, the entire screen is filled with theapplication's main window and displays the camera view grid in thecenter of the window based on the parameters noted above. TheDisplay=Image (or List) sets the initial display type, with “Image”resulting in a display of the view grid 44 with camera images 48 shownin the display windows 46 and “List” providing a textual list of thecameras and servers with no images.

The HighliteFrameColor specifies the hex RGB value for the currentupdate window, that is, it identifies the color used for the borderplaced around the camera window currently being updated at any one timeduring the display loop of FIG. 3. The default color is blue. TheFlashFrameColor provides the hex RGB value for the camera windowcorresponding to the camera for which a trigger has been received. Thedefault color is red. The ViewBackColor specifies the hex RGB value forinactive camera windows, with the default being grey. The TCPPortparameter specifies the IP port on which the camera server transmitsimages and the program 42 application listens. This information is usedin the base CRON script.

The RecordMode setting can either be SINGLE or MULTIPLE, whichrespectively correspond to the single image jpeg and video stream jpxfile formats discussed above. For “Single”, the received images arewritten to disk (or other non-volatile storage media) as a single jpegfile using the naming convention provided above. For “Multiple”, theimages are written as jpx streams, with the RecordMode parameter (“24”shown in FIG. 4) referring to how many jpx files are written per 24hours. This parameter can have any of the following values: 1, 2, 3, 4,6, 8, 12, 24. Thus, “1” means that the received stream of jpegs arewritten into a single jpx file over a 24-hour period, whereas “24” meansthat a new jpx file is started every hour, 24 per day. As mentionedabove, the jpx format is a straight concatenation of jpeg files and, bystoring the files with the .jpx rather than .jpg extension, the softwareavoids the possibility that a user opening the file will inadvertentlylaunch a standard .jpg viewer that might hang due to the large sizes ofthe jpx files.

The RecordThumbnails=TRUE setting is used to tell the software to recordthe displayed thumbnails rather than recording the image at the RecordImage parameter that is specified in the Camera Hardware Setup form ofFIG. 8. This setting causes the program to record the same image that isviewed in the display grid 44. When set to FALSE, the program accessesand displays one image (a thumbnail) from the camera and then accessesand records a second image (at a different size) without viewing. Thisallows for different image sizing and/or compression for viewing thanfor recording.

The RecordlmageBasePath sets the base directory path for recording allimages; that is, it sets the “mapped drive and root path” shown at theupper level of the directory structure shown above. The program willcreate all lower levels of the directory structure if they do notalready exist. An error message is displayed if the drive is notavailable or the directories cannot be created or accessed, and norecording will occur.

The Camera_Database setting is a pointer to the database 56 that is usedfor all camera and camera server settings. Other settings that may beless often accessed are:

DisplayWidth: Sets the default user interface display 44 size in twips.

BorderWidth: Sets the width of the black spacing between all thumbnailimages in pixels.

SkipInactivePorts: TRUE—Thumbnails that are disabled will not bedisplayed when program 42 is running.

ShowHighliteFrames: TRUE to show border around currently updatedthumbnail.

ShowRecordindicators: TRUE to show the record LED status indicator thatcan be included at a corner of the display window for each camera.

ShowCameraCaptions: TRUE to show the title caption at the bottom of thethumbnails.

ShowPortNumbers: TRUE to show the physical thumbnail port numbers.

PingTimeout: The number of milliseconds to attempt a ping to the videoserver before failure abort.

PingOnImageRequest: TRUE to allow ping tests on each received imageburst.

CameraCaptionForeColor: Color of the camera caption in hex RGB

CameraCaptionBackColor: Back color of the camera caption in hex RGB

HTTPPort: Http port number to access all cameras. This is a globalsetting.

MaxFailOverCount: Number of failed camera requests before shutting downthe camera port. The display window 46 will show “Unavailable”.

ReconnectAttemptlntervalSecs: Seconds to elapse before trying toreconnect a failed camera.

DefaultEmailRecipient: Email address to use when sending a motion alert.

EmailUserID: UserlD used for email account access.

EmailUSerPW: User password for email account access.

ShowMotionBorder: TRUE to allow the video motion detection routine tohighlight the target window when motion is detected.

EnableStatusLog: TRUE to allow status info to be written to a text log.

EnableErrorLog: TRUE to allow specific Error information to be writtento a text log.

StreamViewMode: When launching a streamer, the mode it starts in can be:

-   -   0=Icon    -   1=Small frame window with text info only.    -   2=Normal window with video displayed.

StreamIntervalSeconds: Number of seconds to allow the streamer to runbefore closing:

-   -   0=Run forever    -   1 to 84600=1 sec to 24 hrs run time before closing.

StreamMaxFPS: Maximum number of FPS to stream; 0=Max speed

StreamRecord: 0=no record on program launch, 1=record on launch.

Referring now to FIG. 5, there is shown the menu structure for the MainMenu displayed by the program 42 as a part of its user interface. In theDisplay menu, the “List” command displays the cameras as a text gridonly—no image is displayed. The “Thumbnail” command displays the camerasas a graphical grid, displaying images 48 received from the cameras 24using the display loop of FIG. 3. In the Setup menu, the “Hardware”command launches the Hardware Setup form which permits hardwareconfiguration using the process of FIG. 6. The user can add/delete/editthe different server and camera settings. Also in the setup menu is the‘Software’ command which launches a form that allows the user tographically modify the core setting of the .ini file. The ability tomanually edit the file also is available via the ‘Other’ Tab and thenthe first ‘Edit’ button. The ini file can also be edited with any usereditor such as Microsof™ Notepad. The Archive menu contains a singlecommand, “Browse Archived Images” which launches the image viewer 52executable shown in FIG. 10. The Help menu includes a “Dump all ServerSettings” command which writes all server and camera data to a textfile. This information will be located in the application's directory ina file called CameraDump.txt. This information can be useful introubleshooting functional problems with the system.

FIG. 6 depicts the Hardware Setup routine that is invoked by selecting“Hardware” under the Setup menu. This process is used to add or deletecameras and servers, and to edit existing camera or server setups, ifdesired. The servers and cameras are shown in a tree structure on theleft side of a new window on the computer screen and, where an existingserver is selected, a set of server hardware setup tabs (shown in FIG.7) are displayed on the right side of the screen to permit configurationof various server parameters, including many of the control informationitems listed above. Where an existing camera is selected, the camerahardware setup tabs of FIG. 8 are displayed on the right side of thescreen for editing of camera parameters and control information notedabove. All panels for each of the tabs of FIGS. 7 and 8 includes anUpdate button to save changes made on the tab.

For the server hardware setup tabs of FIG. 7, the Connection tabprovides a display that permits the user to set the fundamental serversettings for the program's CGI base parameters. These options are usedin the URL requests to the server. The Connection tab contains the basicserver information. The fields are: Server Name Name to identify theserver. Server Model Name to identify then camera. Server Enabled Checkto enable, uncheck to disable. Server Serial Number Authenticates theserver. Numbers and Letters only. Server IP Address IP address as123.123.123.123 Server Root ID Root user ID. Can also be a regular UserID. Server Root Password Root user PW. Can also be a regular User PW.Server Notes Notes for this Server, for reference only.

If the Server Root ID and Server Root Password are not used, the HostScripting tab will not function. The Connection panel also includes twobuttons: Add New Server Creates a new Server. Delete Server Deletes anexisting Server.

The Switch Inputs tab contains the information related to the digitalinputs on the server and can be used to set the program's preferencesettings for trigger responses from the server. This includes the ShowMotion form, Flash Window, and Record Image options shown in FIG. 3. Theports are disabled by default. The fields are: Switch Port The portbeing edited. Switch Action The action to be performed upon trigger.Switch Caption The name to identify the Switch Action. Enable AudioAlert Enables or Disables an Audio alert segment. Play Audio Windows.wav file to play upon a trigger event.

The Relay Output tab provides a display that permits editing offunctional settings for latching or pulsing the server relay output. Asis known to those skilled in the art, this relay can be attached to asiren, autodialer, or other device compatible with the characteristicsand limitations of the server's relay. The fields are:

-   -   Enable Relay    -   Relay Caption    -   Relay Notes

The Host Scripting tab provides a display for programming or displayingbasic CRON scripts on the server. The basic script allows the server tobroadcast trigger events from the switch inputs. That is, the scriptenables to server to send messages to program 42 that are specific totriggering events on the server such as switch closures, infrared,microwave, magnetic, or other forms of sensors. For example, the baseCRON script used in Axis™ 2400 series servers is:

-   -   0-59 0-23 1-31 1-12 0-6/=xx:    -   alert -host yyy.yyy.yyy.yyy -port zzzz -message “Port Trigger”;

where xx is the server port 1-4, yyy.yyy.yyy.yyy is the IP address ofthe client computer 22, and zzzz is the port specified in the .ini filefor communication between the program 42 and the server. The fields onthis tab are: Enable Script Enable/Disable CRON script activation.Script Text CRON script text.

The Host Scripting panel also contains four buttons: Template Sets abasic CRON script for triggering. Clear Clears the Script window.Download from Server Retrieves existing CRON script from the Server.Upload to Server Sends the Script text to the Server.

For the camera hardware setup tabs of FIG. 8, the Info tab allows theuser to set the camera name, Pan/Tilt/Zoom (PTZ), and text referencefields for each camera, as well as enable or disable the camera. Inparticular, the Info tab includes the following fields: Camera Name Nameof Camera. Camera Model Camera Model; Select from list. Camera EnabledEnables/Disables the Camera Image. Enable Camera Movement Indicateswhether a camera can move. Camera Location This text is for referenceonly. Camera Bldg This text is for reference only. Camera Room This textis for reference only. Camera Room Tel This text is for reference only.Camera Room Contact This text is for reference only. Camera Room ContactTel This text is for reference only. Camera Notes This text is forreference only.

The Presets tab allows the user to define any quantity of user definedpresets for Pan/Tilt/Zoom. The user is shown a thumbnail of a staticsnapshot for any new positional requests. The fields are: Preset ViewsEnables the user to Add/Change Views Preset Notes Text Notes for theselected preset. Pan Pan Value Tilt Tilt Value Zoom Zoom Value

There is one button: H Sets the Preset to HOME

There are three slider controls: Pan Pan Value Tilt Tilt Value Zoom ZoomValue

The Displayed Image tab allows the user to set the image size andcompression level request for the camera server image retrieval. Theseparameters are mapped against CGI type parameters defined by the server.The user representations are simplified terms versus the CGI syntax.Three image styles are defined here. Each style is set for the threeimage request types. This value is used by the server when sendingrequested images to the application. The fields are: Thumbnail ImageMain View with all cameras. Full View Image Detailed View of a singlecamera. Record Image Recorded Image style.

The Thumbnail Image is displayed on the Main form with all the othercamera views. The Full View Image is displayed on the Motion form. TheRecord Image is used whenever a save request is made by the application.Each Image style has a related compression value. The compression valuesare selectable for each Image style. The following considerations shouldbe used when selecting the Image styles:

Image Size

-   -   Largest images: slowest access, largest file size    -   Smallest images: fastest access, smallest file size

Compression Value

-   -   Lowest compression: best image quality, slowest access    -   Highest compression: worst image quality, fastest access

The Switch Inputs tab allows the user to bind any or all availabledigital switch ports to a display window. That is, the digital switchinputs must be bound to camera ports. This setting tells the applicationwhich cameras to record/notify when a trigger event occurs and allowsthe application to notify the user on screen which port trigger(s)is/are associated with a camera view. Each defined switch input islisted with a check box that can be selected to bind the camera to thatswitch input.

As mentioned above in connection with FIG. 3, the Recording setup tabpermits the user to set automatic recording options for intervalrecording a camera. The interval is expressed in seconds. The camerawill record an image at the specified interval if the hardware can meetthese expectations. Otherwise, the image is recorded as quickly aspossible after the interval has expired. The fastest interval that canbe used is derived from observing the cycling rate of all cameras. On aquality system the fastest interval is about ¼ second for any camera.The fields are: Interval Recording The camera will record images at aset interval. Record an Image every . . . The Interval to record imagesautomatically. Compression Index This value sets the save compressionvalue.

The compression value is used by the compression library to set theamount of compression for image saves. The lower the number, the higherthe compression. The range is between 5 and 40. The most commonly-usedvalue is between 30 and 35.

The Email tab permits the user to set an email address to which an emailnotification will be sent upon occurrence of a trigger event. An imagefrom the triggered camera can be attached to the email. The Performancetab permits the user to specify a unique User ID so that the camera orvideo server administrator can set or limit the bandwidth of videotransmission on a user-by-user basis.

When a user double-clicks on a camera window 46, the program 42 bringsup a Motion Form which runs the process shown in FIG. 9. This permitsthe user to bring up a detailed view of the image from a particularcamera, with the image being updated at an increased rate. Completecamera and server information is displayed on this form. The user canPan/Tilt/Zoom supported cameras, click on preset positions, recordimages, or display any trigger events.

FIG. 10 depicts the process flow provided by the image viewer program52, which can be, but need not be, a separate executable than program42. This process can be launched from within program 42 using the“Browse Archive Images” command in the Archive menu of FIG. 5. Thisprogram 52 can include authentication capability to provide the userwith access to only those archived images that have come from serversaccessible to that user. This is indicated in FIG. 10 where the programreads the database for defined servers and parses the record path formatching servers. Then it will display a tree structure showing onlythose archived images and streams that came from cameras or serversdefined in the database for that user. Once the user has selected anarchived jpg or jpx file, the image is brought up on the screen and, forjpx streams, the user can play, pause, stop, frame advance and reviewusing buttons that emulate a VCR panel. A refresh button can also beprovided to reload the archive if additional images are being written toit in the background by the user interface client program 42. The imageviewer program 52 can include an autodelete fimction, in which case afive minute timer is started. The program then checks the archive ageagainst user date settings, and deletes the archived .jpg and .jpx imagefiles that are older than the specified date or time period. The program52 can also include an autoindex feature which, when enabled,automatically indexes the archived jpx files every hour to build anindex into the jpx file for quick access by the program into any pointin the jpx file. This index feature is discussed next. If the autoindexfeature is not enabled, then the index is not built until the first timethe jpx file is loaded.

In installations where very high speed recording is being performed, thejpx file can become quite large. A typical jpx file for an hour of videois 1 to 5 MB, while high speed recording can easily exceed 20 MB andeven reach 100 MB. Since the jpx is purely concatenated JPG images,aligned head to tail, the only way to view the images within the jpxfile is to parse the SOI and EOI markers and display the image inbetween them. For incremental playback, this process is easilycontrolled. However, when a user wants to “rewind”, “fast forward”, orrandomly jump to a portion of video, this process requires the program52 to process from its current position and read all video frames inbetween. Jumping over frames does not work for these files since, inorder to most efficiently store the images, the images within the jpxfile are relatively unique in length. This process of reading in all ofthe frames can be undesirably slow when the jpx file is large. Toovercome this issue, the image viewer program 52 creates an index of theSOI and EOI markers of each image in the jpx file. This index is storedas an array of pointers into the jpx file and is stored using .ndx asits filename extension. The program 52 will look for this index and useit to load the image pointers instead of reading the entire jpx. Theimage pointers identify the memory locations of the SOI and EOI markers,thereby allowing the program to easily locate and retrieve individualimages contained within the jpx file. The ndx file can be loaded in lessthan a second, as compared with jpx load times of up to a minute ormore, depending on jpx size. The index is created on the first useraccess to the jpx image file or when an autoindex event is processed, asdescribed above. Successive requests from the user to a jpx will allowthe program to read the ndx file rather than a conventional approachwhich would entail reading the entire jpx file. With the index file, thepointers can be read into memory and accessed quickly, even for verylarge jpx files.

The ndx index file also makes possible the use of the image viewerprogram 52 as a plug-in for commercially available web browsers. Inconventional browser-based retrieval of video, the video files can bequite large, and the user can therefore typically only request a smallnumber of frames. The user does not know the stream size, frame count,index of time pointers, etc. By implementing the image viewer 52 as aplug-in component for a web browser, viewer can be used to provide webpage access from a web browser to stored jpx images. This alleviates thenecessity of a specialized software product to view the archives. Sincethis image viewer plug-in utilizes the ndx index file, the user canretrieve a wealth of video specific content in a very short period oftime, allowing realtime display of video (assuming the user hassufficient bandwidth) of the Internet or other network.

When implemented as a plug-in, the image viewer 52 can also be used toview “live” a stream that is being recorded on a network server. Thiscan be accomplished using server software that records the jpx files inthe manner described herein, with the image viewer then only parse thetarget jpx file on the network server for the latest video frame. Bydisplaying this video frame, the user sees live video that originatedfrom the camera server, but is being supplied by what can be a muchhigher performance network server. Thus, since the user is now viewingrecorded video from a higher performance server, the number ofsimultaneous connections to the video feed is highly scalable byimplementing standard web server components. This is advantageous sinceall Ethernet video servers are highly susceptible to overload frommultiple user requests and performance is degraded linearly with eachsimultaneous connection.

FIG. 11 depicts the main menu for the image viewer program 52. The“Tree” command under the Browse Mode menu item allows the user to browseall permitted archives by server, camera, date, and type. The “Date”command allows the user to search by date/time for a selected server andcamera. The ‘Directory List’ command lets the user browse all attacheddrives manually. The Indexing command under the Maintenance menu allowsthe user to set the autoindexing features described above. The processused by the image viewer program 52 for setting up the autoindex featureis shown in FIG. 12 a. The “Delete” command under the Maintenance menuallows the user to manually delete archives or automatically deletearchives older than a selected date/time stamp. FIG. 12 b depicts theprocess flow when the “Delete” command is selected. The “FormatConversion” command under the Tools menu allows the user to convertimages to other standardized formats. The Display Mode menu allows theuser to playback the images either as thumbnails (like images 48displayed in the windows 46 generated by the user interface clientprogram 46) or in a cinema (fullscreen) mode.

Rather than using the ActiveX control provided by the camera/servermanufacturer, the user interface client program 42 and stream recorderprogram 50 utilize their own ActiveX control to interface with thecameras and servers. An overview of this OCX control is shown in FIG.13. Further details of the control for obtaining and displaying an imageare shown in FIGS. 14 a-14 c, and further details of the control forobtaining and recording an image are shown in FIG. 15. Theimplementation of a suitable OCX control using the process steps shownin these figures will be known to those skilled in the art and thereforeno further elaboration of the design of this control is necessary.

Referring now to FIG. 16, there is shown the program flow of the streamrecording client program 50, which is a separate executable that permitshigh speed recording of image streams (video) in a manner that minimizesnetwork utilization. The program 50 enables the streaming output fromthe camera servers using the OCX control described above internallywithin the program as direct subroutine calls. Streaming is initiatedusing a CGI enabled URL that is sent in the same manner as describedabove for the user interface client program 42, except that the CGIsyntax is set to zero to indicate streaming output from the server. Asindicated in FIG. 16, the program 50 utilizes a timer to reset theconnection to the server before it is automatically terminated by thenetwork. More specifically, for some networks, such as the Internet, aconnection cannot typically be permanently held, but rather will beterminated automatically after a period of time (e.g., 50-70 minutes).The program 50 avoids this problem and enables nearly uninterruptedstreaming by automatically resetting the connection before the externaltermination and then continuing to append the streaming images onto theend of the jpx file. This can be done with the loss of little or nostreaming data from the camera.

Referring now to FIGS. 17 a and 17 b, the video motion detection routineof program 42 is used to allow the recording of images to be performedonly when a moving subject is present. When enough motion is present,the system will begin recording video until motion has stopped. Whenmotion is sensed according to this routine, the program will perform anyor all of the following functions:

-   -   record video up until video motion is no longer sensed and an        “extra frames” count is exhausted;    -   send an email to a user as selected in the hardware setup panel        based on settings from the .ini file;    -   attach an image to the email of the first frame of video that        motion was detected on;    -   show a yellow border around the target window where motion was        detected;    -   announce motion ON and motion OFF with two wav files, hello.wav        and goodbye.wav, which the user may reset to any sounds        desirable.

FIGS. 17 a and 17 b detail the logic flow of this process. In general,the motion detection routine uses RGB color component filtering of theactual pixel data. By breaking down the image into these components, thevalues of each color component per pixel is represented as a decimalvalue of 0 (No color) to 255 (bright color). These values are comparedto user-defined settings in the program 42 for filtering, allowingspecific component or combined colors to exhibit reduced or enhancedmovement sensitivity. For example, outdoor cameras are very prone tofalse triggering when blowing grass/leaves or shadows are present. Byfiltering out more green component, false triggering is reduced to avery acceptable level. This gives the program the ability to use motiondetection in a much more broad range of use than other comparablesystems.

The process begins by taking the first image (i.e., frame) of a videosequence and placing it into a buffer where it will be used as areference image. The reference image is compared to subsequent videoframes on a pixel-by-pixel basis. Preferably, the reference image iscompared to subsequent images as they are being received (i.e., as soonas they are received) by the client computer so that the program isoperable to provide real time motion detection. For each pixel in thecurrent image, the program performs a comparison of the color componentvalues for that pixel with the color component values of thecorresponding pixel in the reference image. If the difference in colorcomponent values for corresponding pixels from the two images differ bymore than a preselected amount, the program generates a motion detectsignal which can be implemented as the Record Flag shown in FIG. 17 b.For each of the RGB color components, a separate counter (Count_Red,Count_Green, and Count_Blue) is used that tracks the total number ofpixels within the current image for which that color component valuediffers from that of the reference image by more than a preselectedamount. This is done using a user-selectable filter levels for each ofthe color components. In particular, if for a particular RGB colorcomponent, ABS(P_(ref)−P_(cur))−FilterLevel>0 then the Count isincremented for that color component. Separate filter levels are usedfor each color component and these filter levels can be set by the user.As will be appreciated, the FilterLevel is an offset that aids inremoving unwanted noise inherent in video sources, as well as“pixelation” or “tiling” inherent in jpg image sources undercompression. When the entire image is processed, the Count_Red,Count_Green, and Count_Blue counters are compared to a user specifiedminimum, which can be different for each of the color components. If allthree exceed their respective minimums, motion is considered present andthe Record Flag is set to tell the program to proceed with recording.

Once motion is detected, the system records video and continues thepixel comparisons for each subsequent frame until the routine detectsthat motion is no longer present. To prevent the recording from endingbefore a subject has completely left the camera's field of view, theprogram continues recording until a specified number of extra frameshave been recorded. This is carried out using an Extra Frames counterthat is decremented once per frame starting with the first framereceived after no further motion has been detected. As with the othercounters, the number used for this counter can be user specified.Periodically, a new reference frame is selected from the video stream.This is done at regular intervals as specified by a user “RefreshInterval” setting, which is an image frame count. This Refresh Intervalis used in conjunction with a frame counter C_Ref such that, once theC_Ref counter exceeds the Refresh Interval number, the reference bufferis emptied and the counter reset to zero.

The core function of the video motion detection is based on a count ofpixels for which at least one color component value differs from that ofthe reference image by a preselected amount. Minimum object sizedetection can be implemented using the routine of FIGS. 17 a and 17 bwith the addition of an X by Y (width by height) template that scans theX by Y pixel information. If all pixels have a color component valuethat differs from that of the reference image by a preselected amountwithin the X by Y area, motion is detected. The program highlights theobject with a bounding rectangle. This process can be used to filter outobjects that are too small to be considered motion.

Apart from minimum object size detection, the program 42 is alsooperable to permit the user to specify a region of the camera's field ofview so that the program performs the pixel comparisons only for thosepixels located within that region. This region of interest processing isimplemented by providing the user with the ability to mask out specificportions of a video frame, which will then be ignored by the motiondetection. This concentrates the motion detection to specific regions ofthe screen. Typical region of interest masks employ grids or regionsbased on a grid array of squares. These areas are selected to mask outthe regions. This tends to be somewhat granular in use. The program 42uses a pixel based approach to masking the images. The user firstcreates a region of interest by defining the mask using the computermouse to paint a black or other colored area on the image. The paintedareas represent those portions not desired for use in detecting motion.A tool palette of square or other shape may be employed to create thepainted mask. The mask is converted to a black and white mask and savedas a .bmp file based on the camera name. When video motion detection isused by the program, individual pixels from the reference and currentimages will be compared only if the corresponding mask pixel is notblack. Users may edit the mask in Microsoft™ Paint or other image editorto refine the mask to the pixel level.

Implementations of this type of streaming media have a commondifficulty; namely, Ethernet connectivity is at best a highly reliablebut not a totally reliable connection. Occasionally, power fluctuations,excessive image requests, overloaded or failing networks and a multitudeof other issues can cause the connection to the camera to fail.Competing implementations often cause the application to abnormallyabort or stop responding, requiring the user to close and restart theapplication. This condition is very serious since recorded video willnot be available while the program is not responding. The user interfaceclient program 42 and stream recorder client program 50 address thisissue by identifying three modes of failure, and providing contingencyfunctions to overcome these problems. These modes are:

-   -   1. failure upon connect;    -   2. failure upon image request (read); and    -   3. failure during midstream read of image.

Failure types 1 and 2 are easily overcome by the implementation of thedefault timeout of failed requests by the Wininet.dll and its relatedcomponents. The program can count these failures on a per camera basisand optionally shut down the camera and reattempt access periodically.This maximum failure count and reattempt connections are user selectableon a global scale.

Type 3 failures are usually serious and can cause the program to stopresponding. By executing the request asynchronously or in a workerthread, the request can be timed and if abnormally long, cancel therequest and try again. This allows the application to continue tofunction consistently. Preferably, the program utilizes both methods toinsure robust connectivity.

It will thus be apparent that there has been provided in accordance withthe present invention a digital video system and computer programtherefor which achieves the aims and advantages specified herein. Itwill of course be understood that the foregoing description is ofpreferred exemplary embodiments of the invention and that the inventionis not limited to the specific embodiments shown. Various changes andmodifications will become apparent to those skilled in the art. Forexample, although the invention has been described as it would beimplemented using TCP/IP network cameras and camera servers, it will beappreciated that the invention can be used in conjunction with otherimage sources. For example, rather than specifying a URL to access aparticular camera, the invention could be used to specify a memorylocation or utilize a .dll file to access images from, for example, avideo capture card, USB or IEEE-1394 (Firewire) ports. All suchvariations and modifications are intended to come within the scope ofthe appended claims.

1. A method of controlling access by a computer program to a videoserver, comprising the steps of: accessing a video server over a networkfrom a computer using a computer program running on the computer;obtaining from the video server a unique number stored in the videoserver; retrieving at least one authorized unique number; determining ifthe computer program is authorized to access the video server bycomparing the unique number from the video server to the one or moreauthorized unique numbers and, if access is authorized, then initiatinga video stream from the video server to the computer over the network.2. A method of controlling access by a computer program to a hardwaredevice, comprising the steps of: providing a computer program stored incomputer readable form at a computer, the computer being connected to ahardware device via a network; accessing the hardware device from thecomputer over the network using an IP address associated with thehardware device; obtaining a MAC address from the hardware device overthe network; determining if the program is authorized to access thehardware device by validating the MAC address using data accessible tothe client computer; and if program is authorized to access the hardwaredevice, then the method further comprises the step of permitting thecomputer program to retrieve data from the hardware device over thenetwork using the IP address.
 3. A method of licensing a computerprogram on a per-device basis to prevent use of the computer programwith unauthorized hardware devices, comprising the steps of: identifyingone or more authorized hardware devices, each having a MAC address;providing a computer program in computer readable form, wherein thecomputer program is operable upon execution by a computer to permit auser of the computer to input network address information concerning aspecific hardware device accessible to the computer via a network;embedding the MAC address(es) of the authorized hardware device(s) intothe computer program; and executing the computer program on the computerby a user and providing access by the user to the specific hardwaredevice if the specific hardware device has a MAC address that matchesone of the MAC addresses embedded into the computer program.